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DATA TRANSFER METHOD 




FIELD OF THE INVENTION 



The present invention relates to the field of digital data transfer 
& 5 methods, more particularly to the transfer of data in which normal digital data 

=:fs> 

O and encrypted digital data co-exist in the same data. 

2 BACKGROUND OF THE INVENTION 

^ One conventional data transfer method adopts the IEEE 1394 standard 

!"f 10 (IEEE: The Institute of Electrical and Electronics Engineers, Inc.). (Reference: 
J! IEEE Std 1394: 1995, High Performance Serial Bus.) In data transfer specified 

S by the IEEE 1394 standard, there are two methods of communication. One is 

isochronous communication, which is suitable for transferring synchronous data 
such as digital video signals and digital audio signals. The other is asynchronous 
15 communication, which is suitable for transferring asynchronous data such as 
control signals. Both methods of communication are applicable on the IEEE 1394 
bus network. Isochronous communication is what is called Broadcast 
communication, and an isochronous packet output from one device coupled to the 
IEEE 1394 bus is receivable by all the other devices coupled to the same bus. On 
2 0 the other hand, asynchronous communication is applicable to both one-to-one 
communication and one-to-N broadcast communication. Each asynchronous 
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packet output from one device coupled to the bus contains an identifier specifying 
the device(s) to which that packet is addressed. If this identifier specifies a 
particular device, only the device specified by the identifier receives the 
asynchronous packet. If the identifier specifies broadcast, all the devices coupled 
to the same bus receive the asynchronous packet. 

At present, the IEC (International Electrotechnical Commission) is 
preparing to stipulate the IEC 1883 standard (hereafter referred to as AV 
protocol) for transferring digital audio signals and digital video signals or 
transmitting data between devices coupled to an IEEE 1394 bus, employing the 
data transfer method conforming to the IEEE 1394 standard. In the AV protocol, 
video and audio data is located in the isochronous packet as shown in Fig. 5 and 
transferred. The isochronous packet includes a CIP (Common Isochronous 
Packet) header. The CIP header carries information that includes the type of AV 
data, the identification number of the device which is sending the isochronous 
packet, and the like. 

Fig. 5 shows the format of the isochronous packet used in the AV 
protocol. The isochronous packet comprises an isochronous packet header 900, 
header CRC 901, isochronous pay load 902, and data CRC 903. The isochronous 
packet header 900 contains a tag 907. The tag 907 shows that the isochronous 
packet conforms to the AV protocol when its value is 1 . When the value of the 
tag 907 is 1, which means that the isochronous packet conforms to the AV 
protocol, the isochronous pay load 902 has a CIP header 904 at its beginning. The 
CIP header 904 comprises a source ID 906 which identifies the device 
transmitting the isochronous packet. The CIP header 904 also comprises FMT 
908 and FDF 909 which specify the type of actual data 905 in the isochronous 
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payload 902. Digital AV data is contained in the actual data 905, but the actual 
data 905 is not always contained in the isochronous payload 902. Some packets 
may have an isochronous payload 902 which contains only the CIP header 904 
without the actual data 905. 

There is a group of commands called the AV/C Command Set for 
controlling devices in accordance with the AV protocol (Reference: 1394 
TRADE ASSOCIATION Specification for AV/C Digital Interface Command Set 
Version 1.0, September 13, 1996). These commands and their responses are 
transferred by means of asynchronous communication. 

In the conventional data transfer method as described above, 
compatibility with conventional devices which are not designed for transferring 
an encrypted isochronous payload 902 cannot be secured when an encrypted 
isochronous packet, which contains the isochronous payload 902 which has been 
encrypted for copyright protection, is sent. More specifically, conventional 
devices are designed with the precondition that the CIP header 904 is normally 
positioned at the beginning of the isochronous payload 902. Accordingly, if the 
isochronous payload 902 is encrypted, conventional devices cannot correctly read 
out the encrypted CIP header 904, and decide that the isochronous packet does 
not conform to the AV protocol. A device receiving encrypted isochronous 
packets thus may not operate properly. In other words, such receiving devices 
cannot determine the type of data contained in the actual data 905, resulting in an 
inability to identify the device transmitting the isochronous packet. In addition, 
asynchronous communication such as queries to the sending device are disabled. 
Accordingly, normal receiving operations cannot be carried out. 
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Furthermore, if the isochronous packet output from the sending 
device is encrypted while the receiving device is receiving the data, some 
conventional devices may not be able to correctly read out the CIP header 904 as 
soon as encryption starts, resulting in inability to receive data properly. 
5 In order to send AV information encrypted for copyright protection 

from the sending device and decrypt the encrypted AV data by the authorized 
receiving device, the sending device needs to give decrypting information for 
decryption to the authorized receiving device. In the conventional data transfer 
:fi s method, however, the sending device may be required to execute extremely 
S 10 complicated procedures in order to specify the receiving device. More 
ilyj specifically, each isochronous packet contains the source ID 906 which is the 

m identifier of the sending device, but these packets do not contain information that 

identifies which device is authorized to receive these packets. The sending device 
thus cannot check which device is receiving the isochronous packets during 
1^ 15 transmission of the isochronous packets. In order to find which of the devices 
coupled to the IEEE 1394 bus is receiving the data, the sending device may 
require to query the data receiving status of every device coupled to the same 
bus. This makes the procedures for giving key information for decryption 
extremely complicated. 

20 

SUMMARY OF THE INVENTION 

A data transfer method of the present invention satisfies the 
conventional communication standard even in the case of sending encrypted 
video and audio information via isochronous communication. In addition, the 
2 5 present invention offers a data transfer method which prevents erroneous 
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operation even if conventional receiving devices receive isochronous packets 
containing encrypted video and audio data. 

The present invention still further offers a data transfer method 
which significantly simplifies procedures for giving key information for 
decryption from a sending device to an authorized receiving device. 

In a data transfer method of the present invention, synchronous data 
transferred via isochronous communication contains i) encryption identification 
information which indicates encryption status of actual data and ii) actual data, 
and only the actual data is encrypted. 

To solve another problem in the conventional data transfer method, 
the encryption identification information which indicates encryption status of the 
actual data in the synchronous data is sent together with the actual data from the 
sending device, so that receiving device can detect that the actual data is 
encrypted based on this encryption identification information and requests 
decrypting information from the sending device in the data transfer method of the 
present invention. Then, the receiving device receiving the decrypting 
information sent from the sending device upon request decrypts the actual data 
using this decrypting information to complete data transfer. 

Also in the data transfer method of the present invention, the 
receiving device receiving synchronous data checks for the encryption 
identification information contained in the synchronous data. If the receiving 
device detects that the actual data is encrypted, the receiving device requests 
decrypting information for decrypting the actual data from the sending device. 
This request is made using a command in the AV/C set via asynchronous 
communication. At receiving this request, the sending device checks the packet 
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header of received command to identify the device making the request, i.e., the 
receiving device. The sending device then gives decrypting information to the 
identified receiving device using a command via asynchronous communication, 
enabling to realize the data transfer method with extremely simple procedures for 
giving decrypting information from the sending device to the receiving device. 

Moreover, in the data transfer method of the present invention, only 
the actual data in the synchronous data is encrypted, and the encryption 
identification information indicating the encryption status of the actual data is 
included in the synchronous data. This enables to transfer the CIP header without 
being encrypted, preventing erroneous operation when the conventional device 
receives such encrypted synchronous data. In other words, the present invention 
realizes a data transfer method which assures compatibility with the conventional 
data transfer method and eliminates the possibility of erroneous operation when 
the conventional receiving device receives encrypted synchronous data. 

Furthermore, the data transfer method of the present invention 
eliminates the possibility of erroneous operation of the receiving device receiving 
data when encryption of synchronous data starts while continuously receiving 
synchronous data from the sending device because the CIP header is not 
encrypted and transferred as it is. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic view of a format of a CIP header in accordance 
with a preferred embodiment of the present invention. 
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Fig. 2 is a block diagram illustrating functions of sending and 
receiving devices in accordance with the preferred embodiment of the present 
invention. 

Fig. 3A is a format of AKE status command in accordance with the 
preferred embodiment of the present invention. 

Fig. 3B is a format of AKE response to the AKE status command in 
accordance with the preferred embodiment of the present invention. 

Fig. 3C is a format of AKE control command in accordance with the 
preferred embodiment of the present invention. 

Fig. 4 is a schematic view illustrating procedures for transmitting an 
asynchronous packet between sending and receiving devices in accordance with 
the preferred embodiment of the present invention. 

Fig. 5 is a format of isochronous packet in a data transfer method of 
the prior art. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

A preferred embodiment of the present invention is described next 
with reference to the drawings. 

Fig. 1 shows a format of the pay load of an isochronous packet to be 
transferred in the preferred embodiment of the present invention. The preferred 
embodiment is one example of the transfer of a TSP (Transport Packet) in 
accordance with MPEG (the Moving Picture Expert Group) specifications. The 
ENC (hereafter referred to as encryption information) 910 indicates whether the 
actual data 905 is encrypted or not. 
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Fig. 2 shows the relation between sending and receiving devices in 
the preferred embodiment of the present invention. A sending device 110 and 
receiving device 128 are coupled via an IEEE 1394 bus (hereafter referred to as 
a 1394 bus) 111. 

5 First, the functions of each block in the sending device 110 are 

described. 

A signal source 100 outputs an MPEG transport packet TSP (not 
illustrated) in an 188 byte unit, which will be sent via the 1394 bus 111, to an 
encrypter 101. In other words, in the preferred embodiment, the signal source 
*t io 100 outputs data with a fixed length of 188 bytes. The encrypter 101 encrypts 
and outputs the TSP received from the signal source 100 using an encryption key 
109 provided by a key generator 106. In the preferred embodiment, the 
encryption key 109 is equivalent to the decrypting information. An output 
\* command 105 is a command from the key generator 106 to the encrypter 101. 

15 There are three types of commands: normal output, encrypted output, and empty 
H output. If the encrypter 101 receives the output command 105 for normal output, 

the TSP received from the signal source 100 is output without modification, and 
registers the value 0 as the encrypting information 910. If the output command 
105 is for encrypted output, the encrypter 101 encrypts the TSP with the 
20 encryption key 109 received from the key generator 106, and registers the value 
1 as the encrypting information 910. If the output command 105 is for empty 
output, the encrypter 101 outputs an empty signal (not illustrated) every time it 
receives a TSP from the signal source 100, and registers the value 1 as the 
encrypting information 910. A source packet generator 102 adds a 4-byte source 
2 5 packet header to the 188-byte TSP received from the encrypter 101, and outputs 
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a 192-byte source packet (actual data 905). A CIP block generator 103 adds a 
CIP header 954 to the source packet received from the source packet generator 
102, and outputs an isochronous pay load 952. Here, the CIP block generator 103 
places the encrypting information 910 received from the encrypter 101 in the CIP 
5 header 954. An isochronous packet generator 107 adds an isochronous packet 
header 900, header CRC 901, and data CRC 903 to the isochronous payload 952 
received from the CIP block generator 103, and outputs an isochronous packet. 
Since the content of the isochronous payload 952 is data that conforms to the AV 

l: 2 protocol, the value of the tag 907 is set to 1. The key generator 106 sends the 
10 encryption key 109 to the receiving device 128 by communicating the 
asynchronous packet with the receiving device 128, as shown in Fig. 3, which is 

j;L; described later. The key generator 106 also outputs the encryption key 109 to the 

encrypter 101 as described above. 

A 1394 packet I/O controller 108 inputs and outputs isochronous and 

jjj 15 asynchronous packets between the 1394 bus 111 and sending device 110. More 

O specifically, the 1394 packet I/O controller 108 outputs the isochronous packet 

received from the isochronous packet generator 107 and asynchronous packet 
received from the key generator 106 to the 1394 bus 111, and also outputs 
asynchronous packet received from the 1394 bus 111 to the key generator 106. 
20 Next, functions of each block of the receiving device 128 are 

described. 

A 1394 packet I/O controller 127 inputs and outputs isochronous and 
asynchronous packets between the 1394 bus 111 and receiving device 128. More 
specifically, the 1394 packet I/O controller 127 outputs the isochronous packet 
2 5 received from the 1394 bus 111 to a payload extractor 123, and outputs 
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asynchronous packet received from the 1394 bus 111 to a key generator 125. The 
1394 packet I/O controller 127 also outputs asynchronous packet received from 
the key generator 125 to the 1394 bus 111. 

The pay load extractor 123 receives the isochronous packet, 
5 transmitted from the 1394 bus 111, from the 1394 packet I/O controller 127. 
When the value of the isochronous packet tag 907 is 1, the pay load extractor 123 
determines that an isochronous payload 952 contains data conforming to the AV 
protocol, and outputs the isochronous payload 952 to an actual data extractor 
;i 122. When received isochronous payload 952 contains the actual data 905, the 
% 10 actual data extractor 122 outputs the actual data 905 to a decrypter 121, after 
Ji! removing the CIP header 954 placed at the beginning of the isochronous payload 
!;LJ 952. The actual data extractor 122 also outputs the source ID 906 and encrypting 

,^ information 910 extracted from the CIP header 954 to the key generator 125. 

; :s * The encrypting information 910 is also output to the decrypter 121. The key 
]^ 15 generator 125 receives an encryption key 126 as a result of exchanging 
^ asynchronous packet with the sending device 110 via asynchronous 

communication, which is described later, and outputs the encryption key 126 to 
the decrypter 121. When the value of the encrypting information 910 received 
from the actual data extractor 122 is 0, the decrypter 121 outputs the actual data 
20 905 received from the actual data extractor 122 to an AV generator 120 as it is. 
When the value of the encrypting information 910 is 1, the decrypter 121 
decrypts the actual data 905 using the encryption key 126 received from the key 
generator 125, and outputs decrypted actual data 905 to the AV generator 120. 

Next, the transmission of an asynchronous packet via the 
2 5 aforementioned asynchronous communication setup is described. 
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Figs. 3 A to 3 C illustrate how the format of the asynchronous packet 
is transmitted by asynchronous communication. More specifically, Figs. 3 A and 
3C show the command formats of the AKE commands (AKE: Authentication and 
Key Exchange) communicated between the key generators 106 and 125. Fig. 3B 
shows the response format. These commands and responses belong to the AV/C 
Command Set, and are communicated between the sending device 110 and 
receiving device 128 using the asynchronous communication. By communicating 
these commands and responses, the sending device 110 and receiving device 128 
exchange information required for the authentication of each other and 
encryption keys 109 and 126. The AKE commands comprise AKE control 
commands for requesting a target device to carry out a specific operation, and an 
AKE status commands for querying the status and capabilities of the target 
device. 

Fig. 3A shows the format of the AKE status command. In the AKE 
status command, an operation code 208 indicates that this command is an AKE 
command. The value of the algorithm ID 200 is set at 0, with other values 
reserved for future extension. 

Fig. 3B shows the format of responses to the AKE status commands. 
This is a response sent back from the device receiving the AKE status command 
to the device issuing the AKE status command. There are multiple procedures for 
exchanging information for mutual authentication and transmission of encryption 
keys 109 and 126 between the sending device 110 and receiving device 128. In 
an algorithm field 201, the identifier for an information exchange procedure 
which the device returning an applicable response can execute is assigned in bits. 
In other words, the receiving device 128 exchanges several commands and 
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responses with the sending device 110 after an encrypted TSP is detected in line 
with the aforementioned procedures and before receiving the encryption keys 109 
and 126. There is more than one information exchange procedure for 
communicating these commands and responses. The device sending back the 
response designates the executable information exchange procedure by setting 1 
to an applicable bit in the algorithm field 201. Since the size of the algorithm 
field 201 is 16 bits, a maximum of 16 types of information exchange procedures 
can be indicated. The maximum data length 212 indicates the longest receivable 
data length in the form of bytes for exchanging AKE commands and responses. 

Fig. 3C shows the format of the AKE control commands. The 
algorithm field 201 in the AKE control commands set informs of an executed 
information exchange procedure when the value of the algorithm ID 200 is 0. 
Only one bit in the algorithm field 201 of the AKE control command and the 
response to AKE control commands is set at 1, and the other bits are 0. A bit 
having the value 1 indicates the information exchange procedure being used. A 
label 202 is used for identifying correspondence between AKE control 
commands. For example, let's say a certain information exchange procedure 
specifies that the device receiving an AKE control command needs to return a 
different AKE control command corresponding to the AKE control command 
received when the AKE control command is sent from one device to another. In 
this case, the label 202 inserted in the returned AKE control command will have 
the same value as the label 202 inserted in the first AKE control command 
received, in order to clarify the correlation between both AKE control 
commands. In step No. 203, a serial number from 1 is given to each AKE 
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control command in the sequence of communication in the information exchange 
procedure. 

A subfunction 299 takes the values shown in Table 1, and the 
meaning of each AKE command is determined by these values. 



Table 1 



Subfunction 


Value 


Make-response 


0016 


Verify-me 


0116 


Create-key- 


1016 


mformaiion Reconstruct-key 


1116 


Exchange 


2016 



If the subfunction 299 is the make-response, this AKE control 
command challenges the authentication of the device receiving this command. 
Here, the data 207 contains authentication challenge data expressed as random 
numbers to authenticate the receiving device. The device receiving this command 
returns an AKE control command whose subfunction 299 is set to verify-me. 

When returning the AKE control command, the data stored in the 
data 207 is the authentication response data which is a result of a predetermined 
operation with respect to the authentication challenge data in the received data 
207. The key information used for this operation is a key given only to an 
authorized device in advance. Whether the device executing the operation is an 
authorized device or not can be determined by checking the returned 
authentication response data. 

If the subfunction 299 is the create-key-information, this AKE 
control command requests the encryption key 109 to the device receiving this 
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command. The device receiving this AKE control command returns the AKE 
control command whose subfunction 299 is set to reconstruct-key. At this point, 
the encrypted encryption key 109 is stored in the data 207 and returned. 

If the subfunction 299 is the exchange, this AKE control command 
5 requests the exchange of key information between devices sending and receiving 
the command. This key information is stored in the data 207 and transferred for 
indirect authentication between devices or the creation of a common key. 

Values of the subfunction other than those specified in Table 1 are 
s reserved for future extension. The channel No. 204 indicates the channel number 
I;E io for isochronous communication between the sending device 110 and receiving 

?H device 128. This channel No. 204 is valid only when the subfunction 299 is set to 

ii i 

!0 the create-key-information or reconstruct-key. In other cases, this value will be 

set to FF in hexadecimal format. Block No. 205 and total block No. 206 are used 
when data which should be handled by the AKE control command cannot be sent 
W 15 by one AKE command. In this case, applicable data is divided into blocks, and 
O transferred in several transmissions. The total block No. 206 indicates the 

number of divided blocks in applicable data. The block No. 205 indicates the 
number of each block in the data 207. The data length 209 indicates the valid 
data length, as bytes, in the data 207. The data 207 is data exchanged by the 
2 0 AKE control command. The device receiving the AKE control command returns 
a response to that specific AKE control command. The format and value of the 
response are the same as those of the received AKE control command. The only 
detail which differs is that the response does not contain the data 207. 

Fig. 4 shows a time sequence example of AV/C commands which 
2 5 are exchanged between the sending device 110 and receiving device 128 before 
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sending the encryption keys 109 and 126 from the sending device 110 to 
receiving device 128. First, operations of both devices before exchanging AV/C 
commands shown in Fig. 4 are briefly described. 

An initial condition is that non-encrypted TSP is sent from the 
5 sending device 110. The TSP output from the signal source 100 is input to the 
encrypter 101. Since the output command 105 is set to the normal output, the 
encrypter 101 outputs TSP as it is without encryption to the source packet 
generator 102, and registers the value 0 as the encrypting information 910. The 
;^ source packet generator 102 adds 4-byte source packet header to the TSP 

K 10 received, and outputs it to the CIP block generator 103. The CIP block generator 
103 adds 8-byte CIP header 954, and outputs it as isochronous pay load 952 to the 
^ isochronous packet generator 107. Here, the encrypting information 910 

contained in the CIP header 954 is 0 which is input from the encrypter 101. The 
isochronous packet generator 107 adds the isochronous packet header 900, 
lj 15 header CRC 901, and data CRC 903 to the received isochronous pay load 952 to 
Q create the isochronous packet. This isochronous packet is output to the 1394 bus 

111 by the 1394 packet I/O controller 108. Since the applicable isochronous 
packet conforms to the AV protocol, the tag 907 in the isochronous packet 
header 900 is set to 1 . 

20 When the TSP output from the signal source 100 is changed, which 

means that AV information changes from that unprotected AV information to 
copy-protected AV information, the key generator 106 detects this change, and 
changes the output command 105 from the normal output to empty output. At the 
same time, the encryption key 109 for encrypting TSP is given to the encrypter 

25 101. 



MAT-V07839 

-16- 

When the output command 105 is for empty output, the encrypter 
101 outputs an empty signal to the source packet generator 102 every time it 
receives a TSP from the signal source 100, and registers the value 1 as the 
encrypting information 910. At receiving the empty signal from the encrypter 
5 101, the source packet generator 102 transmits the received empty signal as it is 
to the CIP block generator 103 without adding the source packet header. When 
the CIP block generator 103 receives the empty signal, it outputs only the CIP 
header 954 to the isochronous packet generator 107. Here, the encrypting 
5 information 910 in the CIP header 954 uses the value 1 output from the encrypter 
:jr io 101. The isochronous packet generator 107 creates an isochronous packet as the 
j j isochronous payload 952 using the CIP header 954 received from the CIP block 
J;2 generator 103, and outputs it to the 1394 packet I/O controller 108. Since this 

^ isochronous packet conforms to the AV protocol, the value of the tag 907 is set 
to 1. The 1394 packet I/O controller 108 outputs received isochronous packet to 
jU 15 the 1394 bus 111. This isochronous packet is continuously output, and the 
O isochronous packet only containing the CIP header 954 in this isochronous 

payload 952 is continuously output to the 1394 bus 111. The receiving device 
128 receiving this isochronous packet checks its tag 907 by the 1394 packet I/O 
controller 127, detects that the isochronous packet conforms to the AV protocol, 
2 0 and then outputs this isochronous packet to the payload extractor 123. The 
payload extractor 123 extracts the isochronous payload 952 from received 
isochronous packet, and outputs it to the actual data extractor 122. The actual 
data extractor 122 outputs the encrypting information 910 and source ID 906 in 
the CIP header 954 to the key generator 125. After the key generator 125 detects 
2 5 that the value of the encrypting information 910 is 1, the key generator 125 
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learns from the source ID 906 that device outputting the isochronous packet is 
the sending device 110. Then, the key generator 125 finally goes onto a process 
for requesting the encryption keys 109 and 126 using the A/C commands, as 
shown in Fig. 4. 

In Fig. 4, the AKE status command 300 is first sent from the 
receiving device 128 to sending device 110. This enables the receiving device 
128 to query information exchange procedure that can be used by the sending 
device 110. Replying to this query, the sending device 110 returns the AKE 
response 301 to the receiving device 128. Information exchange procedure which 
the sending device 110 can execute is assigned in bits in the algorithm field 201 
of the AKE response 301. This allows the receiving device 128 to learn which 
information exchange procedures can be executed by the sending device 110. For 
example, if the sending device 110 can execute the second and sixth information 
exchange procedures, binary indication in the algorithm field 201 of the AKE 
response 301 will be 0000000000100010. 

The receiving device 128 receiving the AKE response 301 selects 
one optimal procedure from information exchange procedures that both sending 
device 110 and receiving device can execute. Then, AV/C commands are 
exchanged according to the selected exchange procedure. Let's say the receiving 
device 128 can execute the second and eighth information exchange procedures. 
Then, the information exchange procedure which can be executed by both 
sending device 110 and receiving device 128 is only the second procedure. 
Accordingly, the rest of authentication and information exchange are executed 
using the second procedure. In the AKE control command in this procedure, the 
value of algorithm ID 200 will be 0 and the value of the algorithm field 201 will 
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be 0000000000000010 in binary indication. The information exchange procedure 
specifies not only the sequence of exchanging a range of AKE control commands 
but also a format and processing method of the data .207 sent by each AKE 
control command. 

In accordance with the second information exchange procedure, the 
key generator 125 sends the make-response command 302 to the sending device 
110. In the data 207 of this make-response command 302, two random numbers 
RRa and RRb generated by the key generator 125 are encrypted, and the 
algorithm field 201 contains identification information indicating the use of the 
second procedure. The key used for encryption is a common secret key given to 
both authorized sending device and receiving device in advance. The key 
generator 106 receiving the make-response command 302 checks the algorithm 
field 201 of the received make-response command 302, and learns to use the 
second procedure for the rest of the authentication and information exchange. 
Since the key generator 106 can execute the second procedure, the key generator 
106 knows that the data 207 of the make-response command 302 sent in 
accordance with this second procedure contains two random numbers encrypted 
by this secret key. After taking out two random numbers RRa and RRb from the 
data 207 using this secret key, the key generator 106 returns a response 303 to 
inform that a response can be generated. Then, the key generator 106 stores one 
of the random numbers RRa taken out in the data 207, and sends the verify-me 
command 304 to the receiving device 128. This is the response requested by the 
previous make-response command 302. Hereafter, the algorithm field 201 of 
each AKE command exchanged between the sending device 110 and receiving 
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device 128 always contain the identification information indicating the second 
procedure. 

The key generator 125 receiving the verify-me command 304 
confirms that RRa in the data 207 conforms to the random number RRa 
generated by itself, and then returns a response 305 to the verify-me command 
304 to inform that verification has completed successfully. The key generator 
125 then finally authenticates that the sending device 110 is an authorized 
sending device. 

The sending device 110 then use the make-response command 306 
and verify-me command 308 in accordance with the procedures after the make- 
response command 302 described above to confirm that the receiving device 128 
is an authorized receiving device. However, the random number used here is 
RTa and RTb, and the random number sent back by the verify-me command 308 
is RTb. 

Now that both sending device 110 and receiving device 128 know the 
random numbers RRb and RTb, and have confirmed that both are authorized 
devices, the key generator 106 and key generator 125 separately generates a 
temporary key (not illustrated) from RRb and RTb using a common operation 
method specified by the second procedure. These temporary keys are a common 
key only between the sending device 110 and receiving device 128. 

Next, the key generator 125 sends the create-key-information 
command 310 to the sending device 110. A channel number of the isochronous 
packet that the receiving device 128 is currently receiving is stored in the channel 
No. 204 of the create-key-information command 310. The key generator 106 
receiving this create-key-information command 310 encrypts the encryption key 
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109 to be used for encrypting TSP with the aforementioned temporary key, and 
then returns a response 311 to inform that the create-key-information command 
310 has completed successfully. Then, the key generator 106 sends the 
reconstruct-key command 312 which stores the encryption key 109 encrypted by 
the temporary key in its data 207 to the receiving device 128. The key generator 
125 uses the temporary key to decrypt the data 207 of the reconstruct-key 
command 312 received, and obtains the encryption key 126. Then, the key 
generator 125 returns a response 313 to inform that the reconstruct-key command 
312 has completed successfully. Since the encryption keys 109 and 126 are 
encrypted and decrypted using the same temporary key, they are the same keys. 
The encryption key 126 is output from the key generator 125 to the decrypter 
121. This completes the procedure for granting decrypting information. 

The key generator 106 which has sent the reconstruct key command 
312 outputs the output command 105 for encrypted output to the encrypter 101. 
The encrypter 101 receiving this command encrypts TSP received from the 
signal source 100 by the encryption key 109, and starts to output it to the source 
packet generator 102. This enables the sending device 110 to send the 
isochronous packet containing TSP encrypted by the encryption key 109 in its 
isochronous payload 952 on the 1394 bus 111. This isochronous packet received 
by the receiving device 128 is decrypted by the decrypter 121 using the 
encryption key 126 as described above, and outputs the decrypted packet to the 
AV generator 120. 

In the above series of AKE control commands, each set of the make- 
response command 302 and verify -me command 304; make-response command 
306 and verify-me command 308; and create-key-information command 310 and 
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reconstruct-key command 312, respectively has the same label 202. The make- 
response command 302, verify-me command 304, make-response command 306, 
verify-me command 308, create-key-information command 310, and reconstruct- 
key command 312 also have values 1, 2, 3, 4, 5, and 6 in the step No. 203 
5 respectively. 

If the actual data in the isochronous packet output from the sending 
device 110 changes from encrypted actual data to non-encrypted actual data, the 
decrypter 121 detects the change in the encrypting information 910, stops 

l; 3 decryption, and outputs the data received from the actual data extractor 122 as it 

;£ io is to the AV generator 120. 

W If a bus reset occurs in the 1394 bus 111 after the aforementioned 

^ processes shown in Fig. 4 starts, the procedures after and make-response 

^ command 302 need to be repeated. 

i"* As described above, in the preferred embodiment of the present 

IU 15 invention, the sending device sends encrypting information which indicates the 
O encryption status of the actual data in the isochronous packet together with the 

actual data. This enables the receiving device receiving the isochronous packet to 
make a request to the sending device for an encryption key for decrypting the 
actual data if the receiving device detects, by checking the encrypting 
2 0 information in the isochronous packet, that the actual data is encrypted. The 
sending device receiving the request then gives the encryption key to the 
receiving device. Accordingly, the data transfer method of the present invention 
offers extremely simple procedures for giving the encryption key for decryption 
from the sending device to receiving device. 
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Moreover, in the preferred embodiment of the present invention, the 
isochronous packet transferred via isochronous communication contains i) 
encrypting information indicating the encryption status of the actual data and ii) 
actual data, but only the actual data is encrypted for data transfer. This makes 
possible a data transfer method which has no risk of erroneous operation when a 
conventional receiving device receives encrypted actual data while maintaining 
compatibility with the conventional data transfer method. 

Furthermore, in the preferred embodiment of the present invention, 
the CIP header remains non-encrypted for transfer even if encryption of 
synchronous data starts while the receiving device is continuously receiving 
synchronous data sent by the sending device. This enables a data transfer method 
which eliminates the possibility of erroneous operation of the receiving device 
receiving the data. 

In the preferred embodiment, once encryption by the encryption key 
starts, actual data in all transfer units is encrypted and sent. However, it is not 
necessary to encrypt all units of data to be transferred. For example, even if both 
encrypted transfer units and non-encrypted transfer units are sent alternately, the 
receiving device can correctly decrypt the data because encrypting information is 
included in the CIP header, thus achieving the same effect. In addition, it is 
apparent that the same effect is also achievable even if the receiving device 
specifies a percentage of encrypted transfer units to the sending device. The size 
of the MPEG source packet is 192 bytes, with more than one source packet 
stored in one isochronous payload in the case of the high data rate transfer of 
MPEG (12 Mbps minimum). Naturally, however, it is not possible to have both 



MAT-V07839 

-23- 

encrypted source packet and non-encrypted source packet in the same 
isochronous pay load. 

In the preferred embodiment, all actual data is encrypted using the 
encryption key. However, it is not necessary to encrypt all pieces of data. For 
example, the same effect is achievable by encrypting the first half of the actual 
data, or encrypting the first and third quarters of the actual data. In this case, the 
receiving device can decrypt appropriately, if, when sending the data, 
information is inserted to indicate encrypted portions and their percentage in the 
CIP header. The same effect is also achievable by inserting in the CIP header 
encrypting information announcing whether the actual data is encrypted or not. 
The receiving device queries the sending device via asynchronous communication 
about which part of the actual data is encrypted and to what level, when the 
receiving device detects encryption by checking the CIP header. The same effect 
is also achievable in this case even when the receiving device specifies the 
encryption area and percentage to the sending device via asynchronous 
communication. If only the confidential portion in the actual data is encrypted, 
the burden for encryption and decryption is reduced, and at the same time, a 
sufficient effect of encryption may be achieved. 

In the preferred embodiment, the isochronous packet containing only 
the CIP header without actual data is transferred until the completion of mutual 
authentication between the sending and receiving devices. However, the same 
effect is achievable even when an isochronous packet containing encrypted actual 
data is output from the start, and not the isochronous packet containing only the 
CIP header. 
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In the preferred embodiment, procedures for transferring the AKE 
control commands between sending and receiving devices are determined by 
mutual negotiation. However, if the receiving device features only one 
executable procedure, the same effect is achievable by starting to transfer 
5 commands immediately, without executing this negotiation procedure, using only 
the executable procedure. In this case, it may be preferable to specify in advance 
a basic minimum of executable procedures for all authorized devices. 

In this preferred embodiment, direct authentication is implemented 
O between the sending and receiving devices, following which decrypting 

10 information is transferred using a secret key. However, the means for 
transferring authentication and decrypting information is not limited to this 
?H procedure. For example, a public key may be used for mutual indirect 

- authentication and the creation of a temporary key. Decrypting information may 

I"* then be transmitted using this temporary key. Such procedures are briefly 

1U 15 described below. 

O The sending and receiving device stores the key information 

necessary for mutual indirect authentication in the data 207 of the AKE control 
commands, and send this information to each other in line with a procedure 
determined by mutual negotiation. Here, the subfunction 299 is set to the 
20 exchange. This enables both sending and receiving devices to share the same 
temporary key if they are both authorized devices. Decrypting information is 
then transferred using the create-key-information command and reconstruct-key 
command in accordance with the same procedures as those described in the 
preferred embodiment. 




MAT-V07839 

-25- 

In the preferred embodiment, the procedure for transferring AKE 
control commands exchanged between sending and receiving devices is 
determined by mutual negotiation. If the types of procedures executable by the 
sending device are known in advance, the same effect is achievable by having the 
5 receiving device transfer commands using a procedure executable by the sending 
device without first executing this negotiation procedure. 

In the preferred embodiment, procedures for transferring AKE 
control commands exchanged between sending and receiving devices are 
3 determined by mutual negotiation. However, the method for determining transfer 

P 10 procedures is not limited to this one. More specifically, if priority is given in 
.U advance to each of several transfer procedures, the receiving device may start to 

m transfer using the procedure given the highest priority which is executable by 

itself. If the sending device cannot execute that procedure, the receiving device 
tries to transfer data by going down the list of procedures in order of priority 
U 15 until a procedure that is executable by both the sending and receiving device is 
□ found. The AKE control commands are then transferred using this procedure to 

achieve the same effect. 

In the preferred embodiment, the sending device encrypts decrypting 
information which is used for decrypting actual data before transferring it to the 
2 0 receiving device. However, the way the receiving device obtains decrypting 
information is not limited to this procedure. In other words, the sending device 
may provide the receiving device sufficient information for obtaining decrypting 
information, without transferring encrypted decrypting information, and the 
receiving device may obtain decrypting information indirectly from this 
25 information. More specifically, the sending device transfers only the type of hash 
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function to the receiving device, and the receiving device obtains decrypting 
information using the received type of hash function to achieve the same effect. 

The preferred embodiment described above comprises an example of 
the AKE command format. However, the AKE command format is not limited to 
this one. In other words, the AKE command format indicated in this embodiment 
is just one example of how the preferred embodiment may be realized. The same 
effect is achievable by using commands in a different format. 

Industrial applicability 

As described above, the present invention has the significant effect 
of realizing a data transfer method using extremely simple procedures for passing 
key information for decryption from the sending device to the receiving device. 
Encryption identification information indicating the encryption status of actual 
data in synchronous data is sent together with actual data. The receiving device 
receiving the synchronous data checks the encryption identification information 
in the synchronous data, and if it detects that the actual data is encrypted, the 
receiving device requests the sending device for decrypting information for 
decrypting the encrypted data. The sending device receiving this request gives 
the decrypting information to the receiving device. 

The present invention has another significant effect of realizing a 
data transfer method which eliminates the possibility of erroneous operation of 
the receiving device even if conventional receiving device receives encrypted 
synchronous data, while maintaining compatibility with a conventional data 
transfer method. Synchronous data transferred through synchronous 
communication contains i) encryption identification information indicating 
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encryption status of the actual data and ii) actual data, but only the actual data is 
encrypted for data transfer. 

The present invention has still another significant effect of realizing a 
data transfer method which eliminates the possibility of erroneous operation of 
the receiving device even if encryption of synchronous data starts while the 
receiving device continuously receives synchronous data sent from the sending 
device. Synchronous data transferred through synchronous communication 
contains i) encryption identification information indicating encryption status of 
the actual data and ii) actual data, but only the actual data is encrypted for data 
transfer. This enables to transfer the CIP header as it is without being encrypted. 

The present invention has still another significant effect of realizing a 
data transfer method which always executes the most suitable procedure even 
when new and conventional devices share the same network. A procedure for 
transferring and receiving both authentication and decrypting information with 
good future extendibility are achievable by selecting a procedure for providing 
authentication information and decrypting information exchanged between the 
sending and receiving devices by negotiation between the sending and receiving 
devices. In other words, even if a new authentication method or decrypting 
information become available in the future, the most suitable procedure will 
remain selectable by negotiation between devices even if a device which can use 
the new procedure and a device which can use only conventional procedures 
share the same network, as long as the new device is back-compatible with older 
procedures. 

The present invention has still another significant effect of realizing 
decryption even if software which has a low encryption/decryption processing 
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speed is used. The present invention allows the relative proportion of encrypted 
actual data and non-encrypted actual data to be varied. Accordingly, even if the 
receiving device has no exclusive hardware for high-speed data decryption, 
software can be used instead. More specifically, even if the receiving device has 
no hardware for decryption like PC, rapid processing is made possible by 
reducing the proportion of encrypted data in the file and thus shortening the time 
required for the decryption process. 

The present invention has still another significant effect of realizing a 
data transfer method which uses the limited bus transfer band efficiently and 
significantly reduces the risk of unauthorized device receiving readable data. 
Unless the sending and receiving devices mutually authenticate that both are 
authorized devices, isochronous packets without actual data are output. 



